十年•杭研技术秀 | 办公自动化的微服务实践

年

十

2016年对于网易杭州研究院（以下简称“杭研”）而言是重要的 - 成立十周年之际，杭研正式推出了网易云。“十年•杭研技术秀”系列文章，由杭研研发团队倾情奉献，为您展示杭研那些有用、有趣的技术实践经验，涵盖云计算、大前端、信息安全、运维、QA、大数据、人工智能等领域，涉及前沿的分布式、容器、深度学习等技术。正是这些宝贵的实践经验，造就了今天高品质的网易云产品。本文的分享来自杭研运维团队，介绍了将微服务理念应用于办公自动化的尝试，文章重点解析了workflow SDK的设计。

一、背景

微服务理念近几年非常流行，很多企业已经采用或者正在考虑采用它来架构系统，它的核心理念是将大型、复杂的应用分解为各模块化服务，使得系统边界清晰，易于扩展和部署，且具用高内聚低耦合、可重用等优点。

流程在企业运行中无处不在，如果为企业内部开发一套业务系统，那么流程的驱动就是整个系统核心，这种流程驱动部分就是我们所说的“流程引擎”。在办公自动化领域，流程引擎尤其不可或缺。流程引擎提供的服务为流转流程，核心功能单一，那么我们是否可以提供一个流程引擎服务去统一支撑企业的办公自动化呢？ 这样其他应用只需关注自己的业务逻辑，而无需注重流程的流转等基础服务，从而实现技术与业务的分离，这一思路与微服务设计理念非常契合。

于是本人所在团队针对企业应用场景设计了一个流程自动化平台，把流程引擎独立出来形成一个微服务，向任何需要流程引擎服务的系统提供服务。流程引擎服务的设计理念是“我们不参与业务，我们只是业务的搬运工”。

二、流程平台

2.1 技术选型

流程引擎的核心功能是流程流转，目前业界流行的开源流程引擎有Activiti和jBPM，Activiti采用了流程虚拟机技术（PVM），扩展灵活，支持除了BPMN2.0规范之处的流程格式，服务接口清晰，且有良好的社区支持。而jBPM也有其优势，如采用Apache Mina异步通信技术，支持JPA/JTA持久化方面的标准，但其只支持BPMN2.0规范，且社区活跃度不如Activiti。

为了快速构建流程引擎服务，我们在仔细对比了Activiti与jBPM的优劣之后，基于Activiti开发了流程平台并向业务方提供可视化流程设计，流程引擎依据业务方设计的流程图驱动业务流程意图。如图1所示，左侧为流程图元，右侧为流程设计区。

图1 提供可视化流程设计的流程平台

现实需求中，有个人需求和应用需求之分，为满足两种不同的需求，我们的流程平台分成了个人版和应用版。两者最主要的区别在于流程节点相关表单在哪里定义和操作，个人版表单在流程平台上定义操作，而应用版表单在第三方系统上自定义并操作任务，目前平台提供OPEN API与SDK两种应用接入方式。接下来我们重点介绍workflow SDK，目前流程平台SDK只提供了Java版本。

2.2 原子操作

为扩大流程平台的应用范围，我们在流程平台上提供了原子操作概念。所谓原子操作，即可以配置在流程任务节点上无需人工参与的自动化任务，可以是API接口、脚本、系统命令。比如PE、SA、DBA日常运维操作，通过流程引擎把日常工作中有明确流程的操作任务串成一个自动化链条自动一步步执行，并且可能复用，成为提升工作效率的一大利器。

至此，我们提供的流程引擎服务不仅仅局限于传统的企业办公自动化，可以扩展至像包括运维自动化领域、测试自动化领域等具体有专业技术领域的日常操作中。而且个人版和应用版之分覆盖了目前企业中的应用场景，操作方便，如第三方应用只需在系统POM文件中加入workflow SDK的依赖，即可接入流程引擎服务，并且可以自定义流程表单，灵活扩展。

2.3 workflow SDK设计

设计workflow SDK主要目的为方便用户应用接入流程平台，那么如何架构workflow SDK才能达到此目的呢？由于workflow SDK作为平台SDK的特殊性，依赖其提供服务的应用会很多，所以一开始应该认真考虑其整体架构，做到对应用暴露的方法或接口不变并且整体架构容易扩展。

首先我们清楚workflow SDK涉及到两方，一方为应用调用者，另一方为流程引擎服务，而应用方是不关心SDK底层是怎么执行并提供流程引擎服务的，所以在设计workflow SDK时，要做到应用调用者与流程引擎执行分离。应用调用者只需关注与其相关几大接口就可以了，workflow SDK的服务结构图如图2所示：

图2 workflow SDK服务结构图

RuntimeService：在流程平台中，每当一个流程定义被启动一次后，都会生成一个相应的流程对象实例。RuntimeService提供了启动流程、查询流程实例、终止流程等功能。

TaskService：在流程平台中业务流程定义中的每一个执行节点被称为一个Task，对流程中的数据存取，状态变更等操作均需要在Task中完成。Task Service 提供了对用户 Task 和 Form 相关的操作。它提供了运行时任务查询、领取、完成、删除以及变量设置等功能。

HistoryService：用于获取正在运行或已经完成的流程实例的信息, 包含已经持久化存储的永久信息，并已经针对查询优化。

这些Service接口是暴露给第三方应用使用的，后续无特殊情况是不变的。接下来SDK需要做到应用调用者与流程引擎执行分离。在设计模式中，命令模式刚好符合这一应用场景，所以在workflow SDK整体设计引入了命令模式，再者如果我们想在各具体命令执行前后做些额外处理，比如命令执行失败的重试、命令执行的入口log日志等，这又符合责任链模式的应用场景。最后我们在workflow SDK整体设计采用命令模式、责任链模式相结合的方式，即命令执行链模式。使用此模式有如下优点：

1. 实现了调用者与具体命令的执行者的解耦。

2. 更动态的控制，命令模式把请求封装起来，可以动态地对它进行参数化和队列化等操作，从而使得系统更灵活。

3. 更好的扩展性，由于发起命令的对象和具体的实现完全解耦，因此扩展新的命令就很容易，只需要实现新的命令对象，在装配的时候，把具体的实现对象设置到命令对象中，然后就可以使用这个命令对象，已有的实现完全不用变化。

4. 应用责任链模式可以对命令统一处理，比如重试机制。

在执行链中，为方便调试，我们在执行链最开始加入LogInterceptor；同时为了workflow SDK与流程平台的接口加入重试机制，我们在执行链中加入了RetryInterceptor，目前可重试三次。最后才是执行具体的命令。命令执行链模式整体示意图如图3所示：

图3 命令执行链模式

命令拦截器在整个执行链中起着类似链扣的关键作用，即目前的拦截器需执行下一个命令拦截器，CommandInterceptor接口定义如图4所示：

图4 CommandInterceptor接口定义

而整个执行链初始化过程为图5所示：

图5 执行链初始化过程

三、实践

实践是检验真理的唯一方法。目前网易绩效系统后台的流程引擎服务就是我们流程平台提供的。网易绩效系统是一个重业务逻辑的系统，其业务逻辑主要涉及在流程的流转上，而workflow SDK刚好提供了流程引擎服务。网易绩效系统架构如图6所示，其主要由Web服务和workflow服务两部分构成。Web服务绩效系统的页面展示；Redis集群向Web服务提供业务数据缓存服务，如session等；workflow服务主要负责绩效操作流程定义的执行。

图6 网易绩效系统架构图

目前网易绩效系统流程可分为四个阶段，即可由四个子流程组合而成，分别是：目标制定、绩效考评、绩效审核、绩效沟通。每个阶段都存在不同的流程，现在绩效系统接入流程平台，在流程平台上设计出每个阶段的流程，然后四个阶段流程组合就形成一个完整的系统流程。这样每个阶段流程如有调整，只需发布一下流程版本号，无需更改代码即可实现新的业务逻辑的上线，简洁易扩展。

如图7所示，为绩效系统第一阶段目标制定的流程迁移图，红色线表示流程的迁移路线，红框表示流程的当前节点，从此图中可清楚看出当前的流程迁移及当前任务节点，方便用户从全局了解自己的考核流程所处的阶段，避免了传统业务系统的信息局限性。

图7 目标制定阶段的流程迁移图

3.1 问题

虽然流程引擎微服务有诸多优点，但因为采用了分布式架构，它也带来了分布式系统固有复杂性，如分布式系统的事务难以保证，一旦业务数据与流程引擎所用数据出现不一致，可能使业务系统出现意想不到的情况。

3.2 解决方案

为解决分布式事务带来的问题，我们采用数据补偿机制来保证数据的一致性。对所有可能出现数据不一致的地方加入监控，当出现数据不一致的状况时候，我们记录下场景数据，然后调用数据校验方法并做出补偿策略；一旦出现补偿失败就发出报警，我们收到报警后，人工清查数据手动做出补偿。在后续计划中，我们将支持TCC分布式事务。

四、结论

流程引擎微服务有如下优点：

1. 流程引擎模块化与具体的业务系统边界清晰；

2. 不重复造轮子，提升开发效率；

3. 统一管理维护，容易深入优化扩展；

4. 应用范围广，有良好的应用场景。

但微服务有其缺点，会给我们带来挑战，比如分布式系统会引入复杂度、数据无法实时一致性、整个服务需要有完整的机制来保障运行正常等，而目前确实也没有一套成熟通用的解决方案，但是这并不会影响我们拥抱微服务。

未来流程服务平台会丰富通信协议及调用方式和接口多版本管理，提供灵活的在线配置，实时管理和监控，提供数据一致性保障机制，实现多应用租户接入的可靠性、安全性、高并发性，支持业务SLA及报表。

——詹跃荣

网易杭州研究院运维部

小编点评：迭代和扩展成为家常便饭时，微服务化确实符合未来的趋势，对于复杂的应用尤其如此。本文的实践，采用Activiti开源技术和可视化流程设计，让平台的开发和使用都变得更加容易，而命令执行链模式的创新，保证了workflow SDK对业务场景的适应性。诚如作者所言，微服务能够带来明显的好处，实现却有很大的挑战，目前尚无成熟的通用方案，但本文解决的问题并不特别，方法论的借鉴是可以期待的。值得一提的是，网易这样的大型互联网公司对于分布式应用的探索也是步步填坑，要缩短这个流程，需要封装高新技术的产品平台和最佳实践的指导，而网易云产品体系和知识体系的创新，将内部的实践经验服务化，正是要帮助广大程序员和企业组织解决构建互联网业务过程中的一些共性问题，从而实现业务创新的平滑过渡。如果您对微服务有不同的见解，敬请评论切磋。

点击阅读“杭研技术秀”系列文章：